The present invention relates to communicating information in a distributed objects system, and more particularly relates to a publish and subscribe event communications object model and services for delivering events between loosely coupled objects.
A prevalent programming problem is that of advertising availability of and distributing information to interested parties without a priori knowledge of their identity. In these situations, there are two types of programs involved: a program that produces information and one or more programs that consume the information. For efficiency, it is preferable that the information producer proactively notify the interested information consumers when information becomes available, rather than force the consumer to repeatedly call or poll for available information. Yet, the identity of the consumers is not known a priori by the producer (e.g., at development or compile time of the producer program). This programming problem is encountered in a variety of situations from delivering information between very granular objects running in a single process to delivering information across an enterprise between very large applications. For example, it may be desirable to inform several thousand employees of an enterprise when its stock price reaches a given amount, or inform managers when certain tasks in a project are complete, among many other information distribution scenarios. Also, a number of network or enterprise events are of interest to many applications, such as changes in network security policy, replication failures, network printer failure, or moving server software to a new machine. There also are a large number of events that occur within a single machine and have great utility, including login/logout, network connect/disconnect, startup/shutdown, disk full, CPU idle, etc.
Traditional object-oriented programming models and systems use method calls according to a request/reply model to communicate data between objects. Object-oriented programming models, such as the Microsoft Component Object Model (xe2x80x9cCOMxe2x80x9d), define a standard structure of software objects that can be interconnected and collectively assembled into an application (which, being assembled from component objects, is herein referred to as a xe2x80x9ccomponent applicationxe2x80x9d). The objects are hosted in an execution environment created by system services, such as the object execution environments provided by COM. This system exposes services for use by component application objects in the form of application programming interfaces (xe2x80x9cAPIsxe2x80x9d), system-provided objects and system-defined object interfaces.
In accordance with object-oriented programming principles, the component application is a collection of object classes which each model real world or abstract items by combining data to represent the item""s properties with functions to represent the item""s functionality. More specifically, an object is an instance of a programmer-defined type referred to as a class, which exhibits the characteristics of data encapsulation, polymorphism and inheritance. Data encapsulation refers to the combining of data (also referred to as properties of an object) with methods that operate on the data (also referred to as member functions of an object) into a unitary software component (i.e., the object), such that the object hides its internal composition, structure and operation and exposes its functionality to client programs that utilize the object only through one or more interfaces. An interface of the object is a group of semantically related member functions of the object. In other words, the client programs do not access the object""s data directly, but must instead call functions on the object""s interfaces to operate on the data.
Polymorphism refers to the ability to view (i.e., interact with) two similar objects through a common interface, thereby eliminating the need to differentiate between two objects. Inheritance refers to the derivation of different classes of objects from a base class, where the derived classes inherit the properties and characteristics of the base class.
These object-oriented programming models traditionally use a request/reply model to communicate data between objects. In the request/reply model, one object (typically the object that consumes or acts on the information) implements an incoming interface. FIG. 1, for example, shows a program listing 10 according to COM of an xe2x80x9cIStockEventsxe2x80x9d interface exposed by an object to receive communications of stock information, such as stock symbols and price updates. A client of the object (such as one that produces information acted on by the object) communicates with the object through the incoming interface, by first creating the object and calling a method in the interface of the object. FIG. 2, for example, shows a program listing 12 of client code to communicate stock information to the object by calling a method in the IStockEvents interface. In such request/reply models, however, there is a one-to-one relationship between the client and object. Also, the identity of the object must be xe2x80x9cknownxe2x80x9d a priori to the client. Specifically, the relationship of client to object is xe2x80x9cearly-bound,xe2x80x9d i.e., established at development by compiling in a class identifier (e.g., shown in FIG. 2 by the xe2x80x9cCLSID_StockSubscriberxe2x80x9d parameter of the xe2x80x9cCoCreateInstance( )xe2x80x9d call).
A more effective approach to this distribution problem (i.e., of many unknown consumers) is to use a publish and subscribe event communications model, which generally provides an information distribution mechanism that in many ways resembles the magazine publishing industry. In magazine publishing, a publisher (e.g., McGraw-Hill) advertises magazines (e.g., Byte magazine) to potential subscribers. Subscriptions to a given magazine are placed by the subscriber or possibly also by another person on behalf of the subscriber. The subscription is an agreement by the publisher to distribute an event (e.g., issues of the magazine) to the subscriber when the event is produced by the publisher. Publish and subscribe event communications models use a similar approach for distributing information from a producing program (the xe2x80x9cpublisherxe2x80x9d) to a consuming program (the xe2x80x9csubscriberxe2x80x9d).
Two representative publish and subscribe event communications models are Sun Microsystems"" JavaBeans(trademark) Events architecture and the Connection Points model of Microsoft Corporation""s Component Object Model (hereafter, COM Connection Points). Both of these feature an internal events model in which the eventing semantic is completely contained within the scope of the publisher and subscriber. In other words, the subscriber contains the program code that implements the subscription logic.
More specifically, JavaBeans(trademark) Events defines structures of a set of interfaces to be implemented by the publisher and subscriber, as well as an event object with standard interfaces. The publisher (called an xe2x80x9cevent sourcexe2x80x9d) identifies itself as sourcing particular events by implementing registration methods that conform to a specific design pattern (e.g., declared as xe2x80x9cFooListener AddFooListener(FooListener fel);xe2x80x9d in the Java programming language) and accept references to instances of particular subscriber""s (called an xe2x80x9cevent listenerxe2x80x9d) interfaces. The information produced by the event source is encapsulated in an xe2x80x9cevent statexe2x80x9d object (which is derived as a subclass from xe2x80x9cjava.util.EventObjectxe2x80x9d). The subscriber identifies itself as interested in particular events by implementing some set of xe2x80x9cevent listenerxe2x80x9d interfaces with methods that receive the event state object. The subscriber must include code to call the registration method of the publisher and pass a reference to its event listener interface. The publisher, on the other hand, contains code that, upon producing information which is to be published, creates an event state object to contain the information and calls an appropriate method on the registered event listener interfaces of the event listener to which the event state object is passed.
In COM Connection Points, a publisher (called a xe2x80x9cconnectable objectxe2x80x9d) defines outgoing interfaces and provides an associated xe2x80x9cconnection pointxe2x80x9d sub-object for distributing information to interested xe2x80x9cclient objectsxe2x80x9d or subscribers. The connectable object implements an interface, xe2x80x9cIConnectionPointContainer,xe2x80x9d which indicates the existence of outgoing interfaces. The client object uses the xe2x80x9cIConnectionPointContainerxe2x80x9d interface to obtain a reference to an interface, xe2x80x9cIConnectionPoint,xe2x80x9d of the connection point sub-object for a desired outgoing interface (specified by an interface identifier or xe2x80x9cIIDxe2x80x9d) defined by the connectable object. Using the xe2x80x9cIConnectionPointxe2x80x9d interface, the client object establishes an advisory connection with the connectable object by passing in a reference to a sink object that implements the desired outgoing interface. The connectable object then publishes an event via calls to the connected outgoing interfaces.
In both the JavaBeans(trademark) Events and COM Connection Points models, the subscriber is required to contain xe2x80x9csubscription logicxe2x80x9d (i.e., program code) that establishes the subscription or connection from the publisher to the subscriber. In JavaBeans(trademark) Events, the event listener contains logic to locate the appropriate event source that produces event state objects with desired information, and to register its event listener interface with that event source so as to receive the event state object. In COM Connection Points, the client object contains logic to locate the appropriate connectable object that produces desired information, and establish an advisory connection with the connectable object to the client object""s sink interface. This need in such internal event models to incorporate subscription logic built into the publisher and/or subscriber complicates the programming model, making it more difficult for developers to write application objects that make use of the event model for information distribution.
A further disadvantage of these event communications models is that the publisher and subscriber are required to have concurrent lifetimes. In JavaBeans(trademark) Events, the event listener registers an xe2x80x9cevent listenerxe2x80x9d interface reference with the event source. In COM Connection Points, the client object passes a sink object interface reference to the connection point object to establish the advisory connection from the connectable object. In either case, the interface reference is only valid during the lifetime of the event listener or client sink object, requiring that the subscriber and publisher be in existence (i.e., instantiated) when the subscription is made and when the event is published.
The present invention provides a publish and subscribe event communications model in which, among other features, subscribers are externally and loosely coupled to publishers. The event communication model is external in that subscriptions are maintained outside the publisher and subscriber by an event system, so that much of the eventing semantic is removed from the publisher and subscriber. The model also loosely couples the subscriber and the publisher in that the subscriptions are persistent, and the publisher and the subscriber need not have matching lifetimes. In particular, the subscription can be built prior to either the publisher or the subscriber being loaded and running. Further, the subscriber need not be loaded and running when the publisher generates an event, and the publisher need not be loaded and running when the event is delivered to the subscriber.
In an embodiment of the invention illustrated herein, an event is a call to a xe2x80x9csubscribeablexe2x80x9d methodxe2x80x94one which can be subscribed to by a subscriber. The publisher defines an object called an event class, which exposes an interface having methods that are xe2x80x9csubscribeablexe2x80x9d and whose implementation is supplied by the event system. The defined event classes are stored in an events store. Subscriptions can be built for methods in the interfaces of event classes in the events store. The subscriptions specify which subscriber(s) to call whenever a call is made to the subscribed event class method. The subscribers also expose an interface matching the event class interface that contains the subscribed method.
The publisher publishes an event by creating an instance of an event class which exposes the same interface as the subscribers that are to receive the event, and then calling a method in the event class interface. The implementation of the method in the event class issues a counterpart call to every subscriber having a subscription to the event class method. The event class method makes the counterpart call to the matching method and interface of the subscriber.
This event communications model offers several advantages. First, the characteristic of the illustrated event communications model that events are method calls allows event publishing semantics to be removed from the publisher. The publisher issues or xe2x80x9cfiresxe2x80x9d events by simply making a method call, just like a client using request/reply semantics in a traditional object-oriented programming model. Such clients thus can assume the role of a publisher in the illustrated event communications model without alteration. Further, the publisher need not implement event handling code.
The illustrated event communications model has event-handling and subscription code automatically supplied by the event system in an external intermediary, i.e., the event class. This allows the publishing and subscribing of events to be handled in and by system infrastructure, which facilitates easier development of applications using the event model.
The illustrated event communications model also has subscriptions that can be coupled to a subscriber via a class identifier or like program identifier, rather than by an interface pointer or other link to a running program instance. This allows the subscriber""s lifetime to be independent of the publisher and the subscription. The subscriber can be activated (e.g., loaded and run) at the time an event is distributed, and need not exist prior to the eventxe2x80x94including at the creation of the subscription.
The illustrated event communications model further has subscriptions maintained by the event system externally from the publisher and the subscriber. This allows the subscriptions to be placed independent of the publisher and subscriber lifetimes. Since the publisher does not track subscriptions to its events, the publisher need not exist for subscriptions to be placed to the events produced by the publisher.
The illustrated event communications model yet further loosely couples the publisher to its subscriptions and subscribers through use of a class identifier or like program identifier of an event class, rather than interface pointers or like links to running subscribers or subscriptions. This also serves to separate the subscriber and subscription""s lifetimes from the publisher""s lifetime. The publisher issues events to the subscribers for previously placed subscriptions (i.e., subscriptions built prior to the publisher""s existence) by creating an instance of the appropriate event class, and issuing method calls to its interfaces. The event class then multicasts the events to the established subscribers for the event.
The illustrated event communications model additionally maintains persistent subscriptions. Subscriptions are stored by the events system in persistent storage. The subscriptions thus can survive interruptions in machine operation. Also, subscribers can be deactivated after placing a subscription, and later activated when an event is fired.
The illustrated event communications model also permits subscriptions to be placed by other than the subscriber (herein called xe2x80x9cgift subscriptionsxe2x80x9d), such as by an administrative utility and other programs. This allows previously developed objects or object developed by another party to become subscribers by integrating the subscriber objects with other application objects that place the subscription or by an administrator using an administrative utility program to configure the objects as subscribers.
Additional features and advantages of the invention will be made apparent from the following detailed description of an illustrated embodiment which proceeds with reference to the accompanying drawings.